 |
 |
跟 JobStoreTX 一样，我们需要配置一个 Datasource 才能使用 JobStoreCMT。然而，JobStoreCMT 需要两个 Datasource 而不是像 JobStoreTX 只要一个。其中一个 Datasource 和我们为 JobStoreTX 设置的类同：作为不受管理的数据源。同时呢，我们还需配置第二个数据源，是作为受管理的数据源，它由应用服务器来进行管理。
| 为什么 JobStoreCMT 需要两个 Datasource 呢？ JobStoreCMT 的原始作者，Jeffrey Wescott，设计 JobStoreCMT 使用一个标准的 JDBC 连接来做它“自己的工作”，同时，代表客户端(如部署 Job) 的工作在执行时是使用一个在容器控制之下有自身事物的 JDBC 连接。即使 Quartz 处在一个大事物中，这种设计也允许用户与 Quartz 交互，而无需 JobStoreCMT 非得使用应用服务器的事物管理器(例如，经由 UserTransaction) 在做自己内部工作时(如处理已错过执行的 Trigger) 来创建和终止事物。如果是 JobStoreCMT 使用 UserTransation 只给它配置一个数据源，从配置方面来看确实方便。然而，在相比于别的特性需求和改进的必要性时，作此变化并不会成为团队中首要的问题，因而 JobStoreCMT 还是继续要两个数据源。 |
·配置不受管理的数据源
我们在设置不受管理的数据源的多数操作与为 JobStoreTX 所做是相同的，只是我们还要加上一行来指定这是 nonManagedTXDataSource:
# Add the property for the nonManagedTXDataSource
org.quartz.jobStore.nonManagedTXDataSource = myDS
org.quartz.dataSource.myDS.driver = net.sourceforge.jtds.jdbc.Driver
org.quartz.dataSource.myDS.URL = jdbc:jtds:sqlserver://localhost:1433/quartz
org.quartz.dataSource.myDS.user = admin
org.quartz.dataSource.myDS.password = myPassword
org.quartz.dataSource.myDS.maxConnections = 10
这是配置不受管理的数据源，并让 JobStore 知道这个 nonManagedTXDataSource 叫做 "myDS"。
·配置受管理的 Datasource
第二个数据源需配置为一个受管理的 Datasource。这意味着 Quartz 在执行 Scheduler 操作时使用一个容器已创建好的 Datasorce 与数据库交互。当 Quartz 从 Datasource 上取得了连接后，在 Quartz 部署 Job 和 Trigger 时应有一个 JTA 事物。例如，代码要求 Quartz 在 SessionBean 的一个方法上的事物描述符设置为 REQUIRED。另一个应用是客户端程序要通过使用 javax.transaction.UserTransaction 直接启动一个事物。
和不受管理的 Datasoure 一样，也是要在 quartz.properties 文件中配置容器管理的 Datasource。下面的例子描述了如何设置受管理的 Datasource:
org.quartz.dataSource.NAME.jndiURL=jdbc/quartzDS
org.quartz.dataSource.NAME.java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
org.quartz.dataSource.NAME.java.naming.provider.url=t3://localhost:7001
org.quartz.dataSource.NAME.java.naming.security.principal=weblogic
org.quartz.dataSource.NAME.java.naming.security.credentials=weblogic
表 6.6 列出了受管理的 Datasource 可用的属性。
| 属性 | 必须 |
| org.quartz.dataSource.NAME.jndiURL | 是 |
| 描述：受你的应用服务器管理的 DataSource 的 JNDI URL | |
| org.quartz.dataSource.NAME.java.naming.factory.initial | 否 |
| 描述：可选项，你想用的 JNDI InitialContextFactory 的类名称 | |
| org.quartz.dataSource.NAME.java.naming.provider.url | 否 |
| 描述：可选项，连接到 JNDI 上下文的 URL | |
| org.quartz.dataSource.NAME.java.naming.security.principal | 否 |
| 描述：可选项，连接到 JNDI 上下文的用户主体(Unmi 注：用户名) | |
| org.quartz.dataSource.NAME.java.naming.security.credential | 否 |
| 描述：可选项，连接到 JNDI 上下文的用户凭证(Unmi 注：密码) | |
使用到表 6.6 中的属性，这儿有一个在 quartz.properties 中配置受管理的 Datasource 的例子。
org.quartz.dataSource.WL.jndiURL = OraDataSource
org.quartz.dataSource.WL.jndiAlwaysLookup = DB_JNDI_ALWAYS_LOOKUP
org.quartz.dataSource.WL.java.naming.factory.initial = weblogic.jndi.WLInitialContextFactory
org.quartz.dataSource.WL.java.naming.provider.url = t3://localhost:7001
org.quartz.dataSource.WL.java.naming.security.principal = weblogic
org.quartz.dataSource.WL.java.naming.security.credentials = weblogic
------------------------------------------------
[Unmi 后记] 又半月有途未动笔墨了，不过仍然保持着只要有机会上网就一定到 BlogJava 来阅读最新本章的习惯。部门人员锐减，事情也就杂乱不堪起来，对于开发技术的选择上客观上完全能由我自行决断，没有人与我争议了，甚是悲凉。
起初对 Quartz 这个系列的翻译只为一时之兴，一路过来翻译工作其实蛮费时间的。一篇英文阅读完之后，还需花费几近于 20 倍的时间才能用中文记录下来。因为阅读总是眼观六路，一知半解的，完全转换成中文就要字句斟酌了。
翻译进行到这个阶段，我当然还会继续坚持，从其中获得的好处也是不言而喻的。主要表现在两方面：
1. 对技术把握的更精细。阅读是放眼而瞟，只求个大概；翻译则不同，本身未能理解个相当，何以能用中文向他人解译的清楚呢？蕴责任于其中。对于多数例子，并非照搬了事，都有再次测试感受过的。译章置于网上之后，亦有许多朋友就 Quartz 使用时的疑问，本人也会带着某种责任心，尽我能力作解答，也非常有助于自身对该项技术的掌握。
2. 阅读与翻译的速度提升也是显而易见的。最初时的每字每句的爬梳，须频繁请求各方资源才能完成一篇，现在与那时相比，可谓顺畅多了。许多篇章纵使离开英文词典也无碍了。用数据来说吧，现在翻译一篇的速度大概是以前的四至五倍。以后的前行中需要面对更多的英文资料，通过对 Quartz 这个手册翻译扎实锤炼了自己的英文阅读能力，写作能力亦在其内。
之于以上两点能对我产生的影响，尤其是 Quartz 手册的翻译已完成大部分时，我一定还会继续完成它，也非常感谢网络上各位朋友们的支持。
|
|